在某公司的一場溝通訓練課程中， 一位企劃起身表示他在工作上遇到的問題，他大聲的說：「希望工程師可以講人話！不要每次都講那些我聽不懂的東西。」

現在想想，我只覺得他很勇敢...勇敢地曝短。

不說現場其實還有很多工程師，講這話實在不太禮貌，再者，「完全」聽不懂工程師在說什麼，那大概邏輯也不是很好。

扣除掉一些寫程式專有的術語或名詞，大部分工程師會提出跟部門成員討論的項目，大多是使用流程的邏輯判斷問題，很可能是你的企劃書出現了某些不合理的操作，或是針對邏輯判斷，有部分情境不合理、狀態重複、說明不足...

雖然有時候工程師的性格是字字千金，可以簡述絕不多言（？）確實讓人覺得有點難以溝通，但大多數工程師還是蠻願意一起討論的，畢竟大家都是想把事情做好。

所以如果你覺得你的工程師常常不講人話，那也可以想想是否即便是人話你也不一定聽得懂。

在我第一次參加IT鐵人賽的時候其實就寫了不少與工程師配合的小故事，畢竟以當時我的職務經驗來說，最常配合的就是工程師了。

總結幾個項目來跟大家分享就好～若有興趣，大家可以再去挖我的舊文來看看ＸＤ

｜讓工程師知道他可以為你多想些什麼

每個職務都有自己的專業，之所以在一個部門或一間公司裡聚集了那麼多種職類，就是因為要集合大家的長才一起把事情做好。

如果你只給你的工程師「專案時程」，那他就只能在這個時間裡盡自己所能的做出可以運作的產品。

可以的話，前期就讓工程師們一起參與，讓他知道這個產品是為了誰、想解決什麼問題、大家討論時不確定的技術問題是什麼...那我想工程師會很樂意用他的專業幫你想得更多、更遠。

｜盡可能把所有頁面的情境、邏輯都說明清楚

雖然我們不是工程師，可能在一些系統面的狀況比較不熟悉，但在使用情境及狀態上，盡可能完整的交給工程師，會讓工程師更好做事。

每個人做事都有盲點，但你盡力的去條列所有邏輯、狀況，工程師一定也會用他的角度來幫你把關，把他想到的系統狀態提出來跟你討論。

此外，將網站的架構列清楚，資料描述也都統整清楚。這能讓工程師不容易一頭霧水，不曉得哪邊要留動態欄位、哪邊要打api、哪邊要寫死，甚至不知道哪些地方是獨立頁面還是資料切換。在什麼都不清楚的狀況下工作的工程師，很容易感到厭世的，這不是一片雞排、一杯珍奶就可以解決的！（疑）

｜可以質疑，但要記得尊重

這點可能不只適用在工程師，其實 對每個同事 都一樣～
你當然可以質疑，但要記得禮貌與尊重，你可以拿頁面上的效果去詢問工程師，但不能扔出去就問「人家可以這樣做，為什麼你就做不到？」

別忘了開發時程、預算、預估修改幅度、網站支援度...全都不是工程師可以決定的，我想大多數的工程師都很願意一起研究有趣的code或特效，但絕對不是在吵架的時候～

暫時想到的就這樣，其實還有很多小眉角，不過全部寫完可能要寫到明年了（誤）

試著跟你的工程師同事們好好相處吧！工作就是這樣～沒有人是100分無遐零盲點，可以通通靠自己，大家共同把事情做好才是長遠目標！